More than 250,000 copies were printed, and yet, that was not enough to spare me countless programming and management fads. So popular was this title that it earned a 20th Anniversary Edition and still, buzzwords like "pair-programming," "open workspaces," "test driven development," and "military style management" forced their way into my vocabulary.

Frederick P. Brooks, Jr., in 1964, managed the software side in the creation of the IBM 360 Mainframe Computer. Working on the famed project also afforded him a view of the hardware management side, and by way of comparison, he noticed that no developments in software could, or ever would, improve productivity, reliability, and simplicity in the same way hardware improved with advances in electronics, transistors, and large-scale integration. Noting Moore's law, Brooks writes "We cannot expect ever to see two-fold gains every two years."

The essays in The Mythical Man-Month shed light as to why programming is hard to manage, but not in a guru-like manner. Rather, Brooks writes from a position of humility. Of the IBM 360 Operating System:

"... the product was late, it took more more memory than planned, the costs were several times the estimate, and it did not perform very well until several releases after the first."

The essays can be enjoyed in any order, and three have resonated with me. "Chapter 3 The Surgical Team" describes why a balanced team matters, and Brooks asks who is the surgeon and who are the nurses and anesthesiologists on the programming team, how is the work divided, and how does the group communicate?

Brooks found small teams very effective, but the challenge was scaling them up for a project as large as the IBM 360. This was his thesis, and the remaining chapters discuss various techniques at coordination and not succumbing to The Second-System Effect -- another of my favorite essays -- described in Chapter 5. There he writes "The second is the most dangerous system a man ever designs."

An architect building his first system would be circumspect, given his inexperience and the unknowns. He would be careful and restrained, and set aside bells and whistles for perhaps a subsequent release. Not so with his second system, where ambition and hubris could blur, and where temptation would be high to incorporate functional ornaments, and to ignore changes in the technology landscape from when these features were first conceived.

How does an architect avoid the second system effect? Brooks dryly responds "Well, obviously he can't skip his second system." For specific measures, go read the essay for yourself.

Finally, I'd like to point out "Chapter 16 No Silver Bullet" which was added for the 20th Anniversary Edition. Here, Brooks indulges in a wager of sorts, predicting "that a decade would not see any programming technique that would, by itself, bring an order-of-magnitude improvement in software productivity."

Given that the Anniversary Edition was published in 1995 and it is now 2019, and given all the fads I have endured in between, I'd say Brooks won handily. Although an order-of-magnitude is a lot to ask in the software world, No Silver Bullet also tries to identify helpful and unhelpful trends. Of the helpful group, Brooks was prescient regarding Agile Methodology, identifying two of its components:

1. Requirements refinement and rapid prototyping

2. Incremental development -- grow, not build, software

Yes, Agile is a buzzword, but showing promise, it is not a fad. And like Agile Methodology, Brooks argues that the most important component to a software project is people rather than process. Ultimately, bugs, core dumps, and blue screens do not respond to demands, death marches, or heroic measures. They respond to competence and time.